Dynamic Adaptive Streaming over Hypertext Transfer Protocol (DASH), also known as MPEG-DASH, is an approach to content streaming using conventional Hypertext Transfer Protocol (HTTP) web servers equipped with Content Delivery Networks (CDNs). DASH divides content into a series of relatively small HTTP-based file segments as described in a Media Presentation Description (MPD), where the segments represent a very short interval of a content item that is potentially many hours in duration. The content may be provided at a variety of different bit rates, sizes, or qualities. When content is played back using a DASH client, the client automatically selects the next segment in the series to download and play. The size, quality, or bit rate of the selected segment may be chosen based on current network conditions and other factors (e.g., user preference). For example, the client may choose the segment having the highest bit rate that is supported by the underlying network without introducing buffering delay or stuttering.
In Web based content distribution, requests for content from client devices to content portals are typically in the form of content URLs (or more generally Uniform Resource Identifiers (URIs)). Very often content and service providers need to restrict access to content and limit viewing times in order to protect assets and fulfill licensing obligations, for example. Because URLs are inherently open, users, even those authenticated at the portal, can potentially share or expose content URLs with other unauthorized users, or pre-fetch or retain copies of these URLs to access the content outside of an authorized time interval. In other situations, illegal content aggregators can exploit these open URLs to aggregate and re-distribute content without adhering to terms of the original content portals.
URL signing is an effective mechanism for controlling access to URL-addressed content. In particular, URL signing can be used to restrict access to content components accessible via URLs, and control access to the components based on expiration dates and times that limit when content can be accessed.
To achieve these objectives, URL signing can append to a base URL with the following query parameter values:                a client Internet Protocol (IP) address of the user for whom the content access is authorized,        an expiry timestamp to ensure that the content expires after a predetermined time, and        a digital signature over the base URL, the IP address and the timestamp.        
These values can then be validated against an actual client sending in a URL request and the current time at a trusted party (e.g., content server) that is to validate and/or serve the request.
For example, the following is a base URL for a video segment “0.mp4v” having a bit rate of 50 kilobits per second (kbps) with a query parameter size of “medium”:
http://cdn1.example.com/video/500000/0.mp4v?size=medium
It can be signed as follows, resulting in a signed URL:
 http://cdn1.example.com/video/500000/0.mp4v?size=medium&Client=172.16.254.1&Expires=1357034400&Signature=nitfHRCrtziwO2HwPfWw~yYDhUF5EwRunQA-j19DzZrvDh6hQ731Dx~-ar3UocvvRQVw6EkC~GdpGQyyOSKQim-TxAnW7d8F5Kkai9HVx0FIu-5jcQb0UEmatEXAMPLE3ReXySpLSMj0yCd3ZAB4UcBCAqEijkytL6f3VYNGQI6&KeyId=APKA9ONS7QCOWEXAMPLwhere the new query parameters Client, Expires, Signature, and KeyID constitute the URL signing information, and indicate a client IP address, an expiration date and time, a signature over the URL string, and an ID of the key used to create the signature, respectively.
Upon receiving a signed URL, validation can be carried out by a trusted party to determine if the actual request client is indeed the one specified by the Client field, the current time is not beyond the expiration time indicated by Expires, and the signature can be verified (e.g., using the key identified by KeyID). If any of these validations fails, the request is not legitimate and should be denied.
FIG. 1A illustrates an exemplary complete URL 101 comprising a base URL and a query string. The base URL is comprised of a protocol (e.g., HTTP, HTTP Secure (HTTPS), File Transfer Protocol (FTP), Real-time Transport Protocol (RTP), etc.), an address of a webserver, a directory path, and a file name. FIG. 1B illustrates an exemplary signed URL 102 based on the complete URL 101. The signed URL 102 comprises a base URL and a query string as before, and also includes signing information used for access control and/or verification purposes. The signing information comprises client string 103, expires value 104, signature string 105, and keyID string 106.
URL signing has been considered in the context of CDNs and Content Delivery Networks interconnection (CDNi). In CDNi deployment, a signed URL is assumed to be provided by a content service provider to a user client during website or content navigation. When trying to access content, the user's URL request is redirected by the Authoritative CDN and routed via a hierarchy of CDNs from the user client to a surrogate of the Delivering CDN, where the signed URL validation is made before content delivering. Different configurations in a CDNi hierarchy and signature key distribution result in different URL signing models and schemes. How and when to deliver the signed URLs for a large number of base URLs in an efficient and scalable manner make the direct application of URL signing to dynamic adaptive streaming over HTTP (DASH) using media presentation descriptions (MPD) considerably difficult.
The data model of an MPD is mainly described in terms of periods, adaptation sets, representations and segments. There are two basic ways to specify URLs for segments: Segment Lists and Segment Templates. Segment Lists enumerate a list of segment URLs, whereas Segment Templates provide a template-based URL construction mechanism which allows specification of a template containing specific identifiers that are substituted by dynamic values assigned to segments, to represent a list of segments.
Using a Segment Template is more compact and effective, especially when dealing with live streaming content which makes it infeasible to specify a (finite) list of segments at the time of MPD creation. For example, in the following Segment Template-based MPD reproduced in Table A, assuming that the first BaseURL element and the video Representation with id “v1” are selected, the template results in first the Representation-level segment template http://cdn1.example.com/video/50000/$Time$.mp4v.
TABLE A  <?xml version=“1.0”?><MPD   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance   xmlns=“urn:mpeg:DASH:schema:MPD:2011”   xsi:schemaLocation=“urn:mpeg:DASH:schema:MPD:2011 DASH-MPD.xsd”   type=“dynamic”   minimumUpdatePeriod=“PT2S”   timeShiftBufferDepth=“PT30M”   availabilityStartTime=“2011-12-25T12:30:00”   minBufferTime=“PT4S”   profiles=“urn:mpeg:dash:profile:isoff-live:2011”>   <BaseURL>http://cdn1.example.com/</BaseURL>   <BaseURL>http://cdn2.example.com/</BaseURL>   <Period>      <!-- Video -->      <AdaptationSet         mimeType=“video/mp4”         codecs=“avc1.4D401F”         frameRate=“30000/1001”         segmentAlignment=“true”         startWithSAP=“1”>         BaseURL>video/</BaseURL>         <SegmentTemplate timescale=“90000”         initialization=“$Bandwidth%/init.mp4v”         media=“$Bandwidth%/$Time$.mp4v”>         <SegmentTimeline>         <S t=“0” d=“180180” r=“432”/>         </SegmentTimeline>         </SegmentTemplate>         <Representation id=“v0” width=“320” height=“240”         bandwidth=“250000”/>         <Representation id=“v1” width=“640” height=“480”         bandwidth=“500000”/>         <Representation id=“v2” width=“960” height=“720”         bandwidth=“1000000”/>      </AdaptationSet>      <!-- English Audio -->      <AdaptationSet mimeType=“audio/mp4” codecs=“mp4a.0x40”      lang=“en” segmentAlignment=“0” startWithSAP=“1”>      <SegmentTemplate timescale=“48000”      initialization=“audio/en/init.mp4a” media=“audio/en/$Time$.mp4a”>      <SegmentTimeline>      <S t=“0” d=“96000” r=“432”/>      </SegmentTimeline>      </SegmentTemplate>      <Representation id=“a0” bandwidth=“64000”/>      </AdaptationSet>      <!-- French Audio -->      <AdaptationSet mimeType=“audio/mp4” codecs=“mp4a.0x40”      lang=“fr” segmentAlignment=“0” startWithSAP=“1”>      <SegmentTemplate timescale=“48000”      initialization=“audio/fr/init.mp4a” media=“audio/fr/$Time$.mp4a”>      <SegmentTimeline>      <S t=“0” d=“96000” r=“432”/>      </SegmentTimeline>      </SegmentTemplate>      <Representation id=“a0” bandwidth=“64000” />      </AdaptationSet>   </Period></MPD>
The following segment URLs are then generated from the Representation-level segment template:
 http://cdn1.example.com/video/500000/0.mp4vhttp://cdn1.example.com/video/500000/180180.mp4vhttp://cdn1.example.com/video/500000/360360.mp4vhttp://cdn1.example.com/video/500000/540540.mp4vhttp://cdn1.example.com/video/500000/720720.mp4v
However, this Segment Template mechanism makes it difficult to conduct URL signing for segment URLs that are not explicitly specified by an MPD at the time when the MPD is created. Moreover, for the same reasons, it is not feasible to carry signed URLs for segments in the MPD itself, especially for live streaming content.
Because URLs of DASH (media) segments used by CDNs are often specified using segment templates within an MPD, it is not presently feasible to implement URL signing directly for segments, nor to signal and carry signed URLs in an MPD. URL signing is not suitable in its native form to control access to individual segments referenced by URLs. The specification of individual segments using segment templates that enables the client to construct segment URLs at the time of streaming with potential dynamic adaptation makes it infeasible to sign every segment URL when creating an MPD that specifies the segment template, or to distribute these URL signatures to clients efficiently.